home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 27 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.5 KB
  1. From: error@stack.urc.tue.nl (Erlend Nagel)
  2. Subject: Re: Colour.
  3. Date: Tue, 31 May 1994 09:09:34 +0200 (MET DST)
  4. In-Reply-To: <9405310003.AA10852@uqcspe.cs.uq.oz.au> from "Warwick Allison" at May 31, 94 10:03:52 am
  5. Mime-Version: 1.0
  6. Precedence: bulk
  7.  
  8. Warwick wrote:
  9.  
  10. > >Are you sure programmers are going to want to put forth that effort?  
  11. > >It's much easier to just stick together your palette.  How about someone 
  12. > >write a library routine that, given a new palette, sorts them with respect
  13. > >to the palette in place?
  14. > 
  15. > Exactly.  If a library routine is to be provided, then a greater amount
  16. > of effort is justified compared to if just a statement of a standard is
  17. > required.  For a std, it should be simple, or else people won't follow it.
  18. > For a lib routine, extra effort can be employed and the code shared.
  19.  
  20. I favour a solution that is implemented as some sort of system
  21. extension. Since we are dealing with a single resource (a palette) a
  22. single program should manage this resource. It has the added benefit
  23. that programs that are no longer updated will be able to use newer
  24. versions of the colour manager. And it would also be possible for
  25. programs to 'upgrade' that part of the OS, instead of requiring the user
  26. to upgrade to at least TOS 2.06 or something like that.
  27.  
  28. > Match exactly?  That won't work unless you adopt the X11 approach of naming
  29. > colours.  The colour space is too large otherwise (ie. WHICH purple?).
  30.  
  31. But a program could do a request for a colour within a certain margin
  32. from some value.
  33.  
  34. Erlend.
  35.